1. Field of the Invention
This invention is related to the field of processors and, more specifically to address translation in processors.
2. Description of the Related Art
Most modern processors implement address translation. Generally, user programs and even many operating systems (or large portions thereof) execute with address translation enabled. The addresses that are used by the programs are virtual addresses. The virtual addresses are translated to physical addresses that are actually transmitted to the system memory of a computer system that includes the processor, to access memory locations. Different programs in execution in the computer system may be protected from each other's memory accesses, since the mapping of each program's addresses to physical addresses can be controlled. For example, the same (numerical) virtual address generated in different programs can be assigned to different physical addresses, so that the programs access different physical memory. Additionally, a larger virtual memory can be made available to a given program than the actual physical system memory by using disk storage (or other secondary storage) to store less frequently used data from the system memory. The data can be moved back into the system memory when an access occurs.
Generally, if a program generates a virtual address for which there is no current translation, the processor takes a page fault and invokes a page fault handler. The page fault handler can read the corresponding data from secondary storage (if it has been paged out), allocate a physical page for the virtual address and update the translation data to map the virtual address to the physical page, or take other corrective action. A page is the unit of allocation and deallocation in the virtual memory mechanism. Pages are aligned to a page sized address in memory, and can vary in size in some translation mechanisms.
One way to take advantage of virtual addresses (and potentially other hardware virtualization features) is the virtual machine mechanism. Virtualization via a virtual machine has been used in computer systems for a variety of different purposes. For example, virtualization can be used to execute privileged software in a “container” to prevent the privileged software from directly accessing and/or making changes to at least some of the physical machine state without first being permitted to do so by a virtual machine manager (VMM) that controls the virtual machine. Such a container can prevent “buggy” or malicious software from causing problems on the physical machine. Additionally, virtualization can be used to permit two or more privileged programs to execute on the same physical machine concurrently. The privileged programs can be prevented from interfering with each other since access to the physical machine is controlled. Privileged programs may include operating systems, and may also include other software which expects to have full control of the hardware on which the software is executing. In another example, virtualization can be used to execute a privileged program on hardware that differs from the hardware expected by the privileged program.
Generally, virtualization of a processor or computer system may include providing one or more privileged programs with access to a virtual machine (the container mentioned above) over which the privileged program has full control, but the control of the physical machine is retained by the VMM. The virtual machine may include a processor (or processors), memory, and various peripheral devices that the privileged program expects to find in the machine on which it is executing. The virtual machine elements may be implemented by hardware that the VMM allocates to the virtual machine, at least temporarily, and/or may be emulated in software. Each privileged program (and related software in some cases, such as the applications that execute on an operating system) may be referred to herein as a guest. Virtualization may be implemented in software (e.g. the VMM mentioned above) without any specific hardware virtualization support in the physical machine on which the VMM and its virtual machines execute. However, virtualization may be simplified and/or achieve higher performance if some hardware support is provided.
Both the VMM and the guests are executed by the processor(s) included in the physical machine. Accordingly, switching between execution of the VMM and the execution of guests occurs in the processor(s) over time. Particularly, the VMM schedules a guest for execution, and a switch to executing that guest is performed. At various points in time, a switch from executing a guest to executing the VMM also occurs so that the VMM can retain control over the physical machine (e.g. when the guest attempts to access a peripheral device, when a new page of memory is to be allocated to the guest, when it is time for the VMM to schedule another guest, etc.). A switch between a guest and the VMM (in either direction) is often referred to as a “world switch”.
Intercepting certain instructions in the guest causes a world switch to the VMM. Instructions are intercepted for a variety of reasons. For example, an instruction that reads privileged processor state can be intercepted to ensure that the VMM will permit the guest to access the state (or to permit the VMM to perform the access on behalf of the guest). In some cases, the VMM changes processor state from the value that the guest established or expects, and instructions which access the state are intercepted to permit the VMM to supply the expected state instead of the changed state. An instruction that writes privileged state or other processor/system state that the VMM desires to control can be intercepted. In response to each interception, the VMM is invoked to emulate the intercepted event and provide an appropriate response.
In some cases, the VMM can cache information related to a particular intercept (especially a frequently occurring intercept). As long as the same underlying instruction is intercepted, the VMM can used the cached data to speed the processing of the intercept. For example, in some cases, a code sequence that performs the needed processing can be saved and can be executed immediately based on detecting the same intercept for the same instruction. However, ensuring that the same instruction has been intercepted can be problematic, especially if the privileged code within the virtual machine can change translations transparent to the VMM (e.g. in nested page table schemes). Typically, software must walk the page tables to ensure that the same translation exists. One suggested solution to the software table walk is an instruction that can specify the virtual address of the instruction and that can verify that the translation still exists in the translation tables. For example, a solution can include an instruction that has a virtual address operand and a physical address operand. The instruction faults if the virtual address does not translate to the physical address, if there is no translation, or if the translation indicates that the page is not executable. Another solution can include an instruction that has the virtual address operand, translates the address, and returns the physical address and the executable flag from the page table as the result (or faults if there is no translation).